NB-IoT Rel-17

 RAN1#102-e

8.9       Rel-17 enhancements for NB-IoT and LTE-MTC

Please refer to RP-201306 for detailed scope of the WI

R1-2007387        Session notes for 8.9 (Rel-17 enhancements for NB-IoT and LTE-MTC)        Ad-hoc Chair (Samsung)

R1-2006447        Work plan of Rel-17 enhancements for NB-IoT and LTE-MTC        Huawei, Ericsson

Decision: The document is noted.

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2005304        Support of 16QAM for unicast in UL and DL in NB-IoT     Huawei, HiSilicon

·        Proposal 1: For 16-QAM, the DL maximum TBS is 5736 bits.

·        Proposal 2: For 16-QAM, the UL maximum TBS with 2536 bits can be mapped to at least 5 RUs.

·        Proposal 3: Adopt table 3 as the TBS design to support 16-QAM in DL.

·        Proposal 4: Adopt table 4 as the TBS design to support 16-QAM in UL.

·        Proposal 5: The introduction of 16-QAM shall not increase the NPDCCH blind decodes.

·        Proposal 6: The introduction of 16-QAM shall avoid increasing DCI size.

·        Proposal 7: Signal the ratio of NPDSCH EPRE to NRS EPRE for 16-QAM. FFS the detailed signaling.

·        Proposal 8: For 16-QAM, FFS whether or not the PDSCH EPRE is the same in OFDM symbols containing NRS and not containing NRS.

·        Proposal 9: Adopt the simulation assumptions in table 5 and table 6 to evaluate the MCS design.

Decision: The document is noted.

R1-2005837        Support 16QAM for NBIoT          Lenovo, Motorola Mobility

·        Proposal 1: Introduce UE capability signaling for the support of 16QAM for unicast NPDSCH.

·        Proposal 2: To support 16QAM of NPDSCH, the MCS field in DCI format N1 is enlarged or reinterpreted, which needs further discussion.

·        Proposal 3: The configuration of 16QAM for NPDSCH can be enabled/disabled by eNB through RRC signaling.

·        Proposal 4: Network should semi-statically configure three types of NPDSCH EPRE separately.

·        Proposal 5: Introduce UE capability signaling for the support of 16QAM for unicast NPUSCH.

·        Proposal 6: The configuration of 16QAM for NPUSCH can be enabled/disabled by eNB through RRC signaling.

·        Proposal 7: Support 16QAM for NPUSCH needs further study:

o   Option1: Extend TBS table and generate modulation, TBS and MCS table.

o   Option2: Reinterpret the number of resource unit for modulation order of 16QAM.

Decision: The document is noted.

R1-2005941        Design consideration to support 16-QAM for NB-IOT         Sierra Wireless, S.A.

·        New TBS entries shall have a code rate of <=0.85 for all deployment scenarios (i.e. in-band, guard band, stand-alone)

·        To support 16-QAM and higher TBS,

o   The current values in the TBS table are kept

o   Add more columns with new TBS entries. FFS: number of columns and values.

o   For  I_TBS => 9, 16-QAM is used.

·        Agree to a method of calculating the maximum soft buffer size before agreeing to the maximum TBS.

Decision: The document is noted.

R1-2005479         Discussion on UL and DL 16QAM for NB-IoT           ZTE

R1-2005529         Support of 16-QAM for NB-IoT     Nokia, Nokia Shanghai Bell

R1-2005557         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

R1-2005648         Considerations on support of 16QAM for NB-IOT     MediaTek Inc.

R1-2005974         Initial discussion on support of 16 QAM for NB-IoT  Beijing Xiaomi Software Tech

R1-2006192         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

[102-e-LTE-Rel17_NB_IoT_eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT by 8/28

-        Prioritize topics to be resolved in RAN1#102-e by 8/19

R1-2007239        Feature lead summary on 102-e-LTE-Rel17_NB_IoT_eMTC-01      Moderator (Huawei)

Agreement

At least for standalone and guard-band deployments, the maximum TBS to support 16-QAM for unicast in DL is select one option from following:

·         Option 1: 4968 bits with I_SF=7

·         Option 2: 5072 bits with I_SF=7

·         Option 3: 5736 bits with I_SF=7

·         FFS on I_SF>7 for this maximum TBS

FFS for inband deployments

Agreement

Further study on TBS/MCS table design, resource assignment and TBS allocation to support 16QAM in DL considering at least:

·        MCS field size

·        Achievable code rates

·        Avoidance of link-adaptation issues (i.e., large SINR differences between different entries within one TBS row or between different entries in adjacent TBS rows)

·        The break point between different modulation schemes

·        Impacts of deployment modes

·        Indication of modulation scheme for retransmissions

·        Applicability of repetitions

·        UE data rate

Agreement

Further study on TBS/MCS table design, resource assignment and TBS allocation to support 16QAM in UL based at least on the following:

·        MCS field size

·        Achievable code rates

·        Avoidance of link-adaptation issues (i.e., large SINR differences between different entries within one TBS row or between different entries in adjacent TBS rows)

·        Throughput/UE data rate increase while keeping the max TBS from Rel-16

·        The break point between different modulation schemes

·        Indication of modulation scheme for retransmissions

·        Applicability of repetitions

·        Applicability to different number of subcarriers

Agreement

For DL power allocation, support signaling the ratio of NPDSCH EPRE to NRS EPRE. FFS signaling details, including how/whether to signal the ratio for the following cases

·        NPDSCH in symbols without NRS and CRS

·        NPDSCH in symbols with CRS (only for “In-band” deployment)

·        NPDSCH in symbols with NRS

Agreement

·        Adopt the following evaluation assumptions for support of 16QAM in DL and UL for NB-IoT

<Simulation assumptions for DL>

<Simulation assumptions for UL>

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2005480        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC             ZTE

·        Proposal: Introduce an additional bit in DCI when 14 HARQ processes are configured.

·        The additional bit and HARQ-ACK delay field are jointly coded to indicate the PDSCH scheduling delay and HARQ-ACK delay.

Decision: The document is noted.

R1-2005558        Support of 14 HARQ processes in DL in LTE-MTC             Ericsson

·        Proposal 1: The design to support “14 HARQ processes in DL using HARQ-ACK bundling for a Cat M1 HD-FDD UE” includes the possibility of operating in presence of invalid subframes (i.e., non-BL/CE DL subframes and non-BL/CE UL subframes), and measurement gaps.

Decision: The document is noted.

R1-2005305         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2005530         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

R1-2005940         Design considerations to support 14-HARQ for LTE-M            Sierra Wireless, S.A.

R1-2005973         Initial discussion on support of additional PDSCH scheduling delay for introduction of 14 HARQ processes in DL for eMTC        Beijing Xiaomi Software Tech

R1-2006193         Support of 14 HARQ processes and scheduling delay Qualcomm Incorporated

[102-e-LTE-Rel17_NB_IoT_eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC by 8/28

-        Prioritize topics to be resolved in RAN1#102-e by 8/19

R1-2007265        Feature Lead Summary: [102-e-LTE-Rel17_NB_IoT_eMTC-02]     Moderator (Ericsson)

Agreement

Introduce a new RRC configuration parameter to enable 14 HARQ processes.

Agreement

For a UE configured with 14 HARQ processes, a PDSCH scheduling delay of 2 BL/CE DL subframes and 7 [FFS subframes type(s)] is supported at least in the PUCCH non-repetition case:

• FFS details of signaling.
• FFS other delay values to account for the presence of non-BL/CE subframes in the PUCCH non-repetition case.
• FFS if the 14 HARQ processes feature is supported in PUCCH repetition case.

Working Assumption

·        Introduce a new optional UE capability to support 14 HARQ processes.

8.9.33        Other

R1-2005481         DL TBS increase for eMTC             ZTE

R1-2006448         Channel quality reporting in NB-IoT to support 16QAM          Huawei, HiSilicon

R1-2006463         On the support of a maximum DL TBS of 1736 bits in LTE-MTC          Ericsson

 RAN1#103-e

8.9       Rel-17 enhancements for NB-IoT and LTE-MTC

Please refer to RP-201306 for detailed scope of the WI

R1-2009836        Session notes for 8.9 (Rel-17 enhancements for NB-IoT and LTE-MTC)        Ad-hoc Chair (Samsung)

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2007618         Support of 16QAM for unicast in UL and DL in NB-IoT           Huawei, HiSilicon

R1-2008073         Support of 16-QAM for NB-IoT     Nokia, Nokia Shanghai Bell

R1-2008697         Discussion on UL and DL 16QAM for NB-IoT           ZTE

R1-2008920         Support 16QAM for NBIoT             Lenovo, Motorola Mobility

R1-2008930         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

R1-2008969         Further considerations on support of 16QAM for NB-IOT        MediaTek Inc.

R1-2009112         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

R1-2009125         Design considerations to support 16-QAM for NB-IOT             Sierra Wireless, S.A.

[103-e-LTE-Rel17_NB_IoT_eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT

• 1^st check point: 11/5
• 2^nd check point: 11/10
• 3^rd check point: 11/12

R1-2009477        Feature lead summary #1 on [103-e-LTE-Rel17_NB_IoT_eMTC-01]               Moderator (Huawei)

Decision: From GTW session on Nov.2^nd,

Agreement

At least for standalone and guard-band deployments, the maximum TBS to support 16-QAM for unicast in DL is 4968 bits with ISF=7.

Agreement

For inband deployment, the maximum TBS to support 16-QAM for unicast in DL is 3624 bits (ISF=7).

Agreement

Different breaking points (QPSKà16QAM) are used for standalone/guardband and inband deployments.

• FFS the details of the breaking point.

Decision: As per email decision posted on Nov.8^th,

Agreement

Explicit or implicit signaling of power ratios of NPDSCH EPRE to NRS EPRE for the following cases is supported.

·        NPDSCH in symbols without NRS and CRS

·        NPDSCH in symbols with CRS (only for “In-band” deployment)

·        NPDSCH in symbols with NRS

Agreement

For 16-QAM in NB-IoT, separate optional UE capabilities for UL and DL are supported:

·        The support of 16QAM in DL is indicated by an optional UE capability signaling.

·        The support of 16QAM in UL is indicated by an optional UE capability signaling.

Agreement

For 16-QAM in NB-IoT, separate UE-specific RRC signaling for UL and DL are supported:

·        16QAM for UL is configured by UE-specific RRC signaling.

·        16QAM for DL is configured by UE-specific RRC signaling.

Decision: From GTW session on Nov.9^th,

Working Assumption

·        The following TBS indices are introduced for downlink

·        FFS: Support of legacy TBS indices with 16-QAM at least for some deployment modes.

·        FFS: Mapping of (a subset of) TBS entries to modulation schemes for different deployment modes.

·        FFS for I_SF > 7

Working Assumption

·        The following TBS indices are introduced for uplink

R1-2009658        Feature lead summary #2 on [103-e-LTE-Rel17_NB_IoT_eMTC-01]               Moderator (Huawei)

Working Assumption

·        For standalone and guardband deployments, the downlink TBS entries between 14 (TBS of 2856 for I_SF=7) and 21 are used for 16QAM.

·        For inband deployments, the downlink TBS entries between 11 (TBS of 2024 for I_SF=7) and [17] are used for 16QAM.

Agreement

Repetitions larger than 2 are not supported in case of 16QAM for downlink

·        FFS: Whether repetition of 2 is supported or not

R1-2009730        Feature lead summary #3 on [103-e-LTE-Rel17_NB_IoT_eMTC-01]               Moderator (Huawei)

Decision: From GTW session on Nov.12^th,

Agreement

16QAM can be used at least for multi-tone transmission with 12 subcarriers.

-        FFS: 3 and 6 subcarriers.

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2007619         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2008074         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

R1-2008698         Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC  ZTE

R1-2008931         Support of 14 HARQ processes in DL in LTE-MTC   Ericsson, Telefónica, Verizon, SoftBank, AT&T, Telstra

R1-2009113         Support of 14 HARQ processes and scheduling delay Qualcomm Incorporated

R1-2009124         Design considerations to support 14-HARQ Feature for LTE-M             Sierra Wireless, S.A.

[103-e-LTE-Rel17_NB_IoT_eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

• 1^st check point: 11/5
• 2^nd check point: 11/10
• 3^rd check point: 11/12

R1-2009513        Feature Lead Summary [103-e-LTE-Rel17_NB_IoT_eMTC-02]       Moderator (Ericsson)

Decision: From GTW session on Nov.4^th,

Agreement: The following working assumption is confirmed

·        Introduce a new optional UE capability to support 14 HARQ processes

Agreement

The design of the 14 HARQ processes feature accounts for the presence of non-BL/CE UL and DL subframes in the PUCCH non-repetition case.

• FFS: PDSCH scheduling delays
• FFS: HARQ-ACK delays
• FFS: Configurable/dynamic set of PDSCH delays/HARQ-ACK delays

For future meetings:

Companies to further study on the impact of measurement gaps on the 14 HARQ processes feature.

R1-2009514        Feature Lead Summary#2 [103-e-LTE-Rel17_NB_IoT_eMTC-02]  Moderator (Ericsson)

Decision: From GTW session on Nov.11^th,

Agreement

For the support of 14 HARQ processes, the solution to assign PDSCH scheduling delays should be able to minimize unnecessary waste of subframes derived from the presence of non-BL/CE DL subframes and non-BL/CE UL subframes.

• The following solutions will be further investigated:
• The indication of subframe types for the PDSCH scheduling delay of 7 are:
• 1 BL/CE DL subframe + 1 subframe + 3 [BL/CE UL subframes] + 1 subframe + 1 BL/CE DL subframe.
• 1 subframe + 3 [BL/CE UL subframes] + 1 subframe + 2 BL/CE DL subframes.
• Configurable delays including other values than 2 and 7.
• Other solutions are not precluded.

Agreement

For the support of 14 HARQ processes, the solution to assign HARQ-ACK delays should aim to maximize the number of HARQ processes that can be scheduled in presence of non-BL/CE DL subframes and non-BL/CE UL subframes.

• Different percentages of presence of non-BL/CE subframes can be analyzed as to represent typical scenarios and determine which HARQ-ACK delays should be included.

R1-2009515        Feature Lead Summary#3 [103-e-LTE-Rel17_NB_IoT_eMTC-02]  Moderator (Ericsson)

No further progress.

8.9.33        Other

R1-2007620         Channel quality reporting in NB-IoT to support 16QAM          Huawei, HiSilicon

R1-2008699         DL TBS increase for eMTC             ZTE

R1-2008932         On the support of a maximum DL TBS of 1736 bits in LTE-MTC          Ericsson

 RAN1#104-e

8.9       Rel-17 enhancements for NB-IoT and LTE-MTC

Please refer to RP-201306 for detailed scope of the WI

R1-2102195        Session notes for 8.9 (Rel-17 enhancements for NB-IoT and LTE-MTC)        Ad-hoc Chair (Samsung)

R1-2101280         Work plan of Rel-17 enhancements for NB-IoT and LTE-MTC              Huawei, Ericsson

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2100253         Support of 16QAM for unicast in UL and DL in NB-IoT           Huawei, HiSilicon

R1-2100507         Support of 16-QAM for NB-IoT     Nokia, Nokia Shanghai Bell

R1-2100567         Discussion on UL and DL 16QAM for NB-IoT           ZTE

R1-2100581         Consideration on CQI report and Repetition applicability for 16QAM in R17               MediaTek Inc.

R1-2100762         Support 16QAM for NBIoT             Lenovo, Motorola Mobility

R1-2101324         Design considerations to support 16-QAM for NB-IOT             Sierra Wireless, S.A.

R1-2101509         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

R1-2101698         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

[104-e-LTE-Rel17_NB_IoT_eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT

-        1^st check point: Jan 27

-        2^nd check point: Feb 1

-        3^rd check point: Feb 5

R1-2101868        Feature lead summary #1 on 104-e-LTE-Rel17_NB_IoT_eMTC-01 Moderator (Huawei)

Decision: As per email decision posted on Jan 28^th,

Agreement

DL 16-QAM is applicable for NPDSCH scheduled from a DCI with CRC scrambled by C-RNTI.

·        At least C-RNTI from USS is supported, FFS if 16-QAM is applied to C-RNTI from CSS.

·        FFS: Applicability of 16-QAM for PUR.

Agreement

Repetition is not used for 16-QAM in uplink.

Agreement

UL 16-QAM is applicable for NPUSCH scheduled from a DCI with CRC scrambled by C-RNTI.

·        At least C-RNTI from USS is supported, FFS if 16-QAM is applied to C-RNTI from CSS.

·        FFS: Applicability of 16-QAM for PUR or EDT.

Agreement

The soft buffer size for Cat. NB2 UEs supporting 16QAM for downlink is 12800 bits.

R1-2102030        Feature lead summary #2 on 104-e-LTE-Rel17_NB_IoT_eMTC-01 Moderator (Huawei)

Working Assumption

The previous working assumption on the following TBS indices for downlink is updated with following modifications:

Agreement

I_SF>7 is not supported in Rel-17.

Agreement

Confirm the following working assumption:

·        The following TBS indices are introduced for uplink

Agreement

The following working assumption is confirmed with following modifications:

·        For inband deployments, the downlink TBS entries between 11 (TBS of 2024 for I_SF=7) and [17] are used for 16QAM.

Agreement

Repetition of 2 is NOT supported for 16-QAM in downlink.

Agreement

On the breaking point between QPSK and 16QAM for NPUSCH, the UL TBS entries only between 14 and 21 are used for 16QAM if 16QAM is configured.

Agreement

16-QAM can be used for 3 and 6 subcarriers NPUSCH format 1

Agreement

The NPDSCH EPRE in symbols with NRS can be different and can be the same with the NPDSCH EPRE in symbols without CRS and NRS.

·        FFS on signaling details

·        FFS for the handling on whether the PCI is different or the same

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2100254         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2100508         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

R1-2100568         Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC  ZTE

R1-2101325         Design considerations to support 14-HARQ Feature for LTE-M             Sierra Wireless, S.A.

R1-2101510         Support of 14 HARQ processes and scheduling delay Qualcomm Incorporated

R1-2101699         Support of 14 HARQ processes in DL in LTE-MTC   Ericsson, AT&T, SoftBank, Telefónica, Verizon

[104-e-LTE-Rel17_NB_IoT_eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

-        1^st check point: Jan 27

-        2^nd check point: Feb 1

-        3^rd check point: Feb 5

R1-2101845        Feature Lead Summary [104-e-LTE-Rel17_NB_IoT_eMTC-02] 1st check point               Moderator (Ericsson)

Agreement

The PDSCH scheduling delay for the PUCCH non-repetition case (i.e., PUCCH repetitions = 1):

·        2 BL/CE DL subframes.

·        The PDSCH scheduling delay of 7 is expressed as:

o   1 BL/CE DL subframe + 1 subframe + [3 subframes] + 1 subframe + 1 BL/CE DL subframe.

o   1 subframe + [3 subframes] + 1 subframe + 2 BL/CE DL subframes.

R1-2101846        Feature Lead Summary [104-e-LTE-Rel17_NB_IoT_eMTC-02] 2nd check point               Moderator (Ericsson)

R1-2101847        Feature Lead Summary [104-e-LTE-Rel17_NB_IoT_eMTC-02] 3rd check point               Moderator (Ericsson)

From GTW session on Feb 4^th,

Agreement

For the 14 HARQ processes feature, when PUCCH is used with 1 repetition and there is presence of non-BL/CE UL subframes (i.e., invalid UL subframes):

·        The term surrounded by brackets in Solution 1 is resolved as 3 BL/CE UL subframes.

8.9.3        Support a maximum DL TBS of 1736 bits as a Rel-17 optional UE capability

For HD-FDD Cat. M1 UEs in CE mode A only

R1-2100255         Support of a max DL TBS of 1736 bits in LTE-MTC Huawei, HiSilicon

R1-2100509         Support of a maximum DL TBS of 1736 bits for eMTC            Nokia, Nokia Shanghai Bell

R1-2100569         DL TBS increase for eMTC             ZTE

R1-2100869         Support of 1736 bit maximum DL TBS for eMTC      Sony

R1-2101326         Design considerations to support DL TBS of 1736 bits for LTE-M         Sierra Wireless, S.A.

R1-2101511         Support of larger TBS for eMTC     Qualcomm Incorporated

R1-2101700         Support of a maximum DL TBS of 1736 bits in LTE-MTC      Ericsson

[104-e-LTE-Rel17_NB_IoT_eMTC-03] – Martin (Sony)

Email discussion on support of a max TBS of 1763 bits

-        1^st check point: Jan 27

-        2^nd check point: Feb 1

-        3^rd check point: Feb 5

R1-2101908        Feature Lead Summary [104-e-LTE-Rel17_NB_IoT_eMTC-03] 1st check point               Moderator (Sony)

From GTW session:

Agreement

The number of soft channel bits is calculated based on the equation:

Working Assumption: N=8

Conclusion

It is RAN1 assumption that 1736 DL TBS feature is compatible with all other eMTC features applicable for HD-FDD Cat. M1 UEs in CE mode A. It is assumed that there’s no change to DCI formats, TBS tables and CQI tables.

R1-2102124        Feature Lead Summary [104-e-LTE-Rel17_NB_IoT_eMTC-03] 2nd check point               Moderator (Sony)

From GTW session:

Agreement

The 1736 bits DL TBS feature is enabled by unicast RRC configuration.

Decision: As per email posted on Feb 5^th,

Agreement

For a UE configured with “1736 bits DL TBS” and 64-QAM:

·        If the UE is signaled with a TBS of up to and including 1736 bits, the UE shall apply the signaled TBS.

·        If the UE is signaled with a TBS of greater than 1736 bits, the UE shall apply a TBS of 1736 bits.

8.9.44        Other

R1-2100570         Channel quality report for 16QAM in NB-IoT             ZTE

R1-2101278         Channel quality reporting in NB-IoT to support 16QAM          Huawei, HiSilicon

R1-2101701         Compendium of 16-QAM simulation results in UL and DL for NB-IoT Ericsson

 RAN1#104-bis-e

8.9       Rel-17 enhancements for NB-IoT and LTE-MTC

Please refer to RP-201306 for detailed scope of the WI

R1-2103983        Session notes for 8.9 (Rel-17 enhancements for NB-IoT and LTE-MTC)        Ad-hoc Chair (Samsung)

R1-2103763         Work plan of Rel-17 enhancements for NB-IoT and LTE-MTC              Huawei, Ericsson

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2102357         Support of 16QAM for unicast in UL and DL in NB-IoT           Huawei, HiSilicon

R1-2102652         Support of 16-QAM for NB-IoT     Nokia, Nokia Shanghai Bell

R1-2102680         Switching point between QPSK and 16QAM and DCI design for 16QAM in R17               MediaTek Inc.

R1-2102857         Discussion on UL and DL 16QAM for NB-IoT           ZTE

R1-2103067         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

R1-2103531         Support 16QAM for NBIoT             Lenovo, Motorola Mobility

R1-2103723         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

[104b-e-LTE-Rel17_NB_IoT_eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT

-        1^st check point: April 15

-        2^nd check point: April 20

R1-2103853        Feature lead summary #1 on 104b-e-LTE-Rel17_NB_IoT_eMTC-01               Moderator (Huawei)

Agreement

Confirm the working assumption that the following TBS indices are introduced for downlink with modification in RED:

Agreement

Confirm the working assumption:

·        For standalone and guardband deployments, the downlink TBS entries between 14 (TBS of 2856 for I_SF=7) and 21 are used for 16QAM.

Agreement

For both uplink and downlink

• 16-QAM is not applied to C-RNTI from CSS.
• 16-QAM is not applied to EDT.

Working Assumption

The DCI size is not increased to support 16-QAM in uplink and downlink.

R1-2103954        Feature lead summary #2 on 104b-e-LTE-Rel17_NB_IoT_eMTC-01               Moderator (Huawei)

Agreement

The following options on the indication of downlink 16-QAM can be considered:

• Option 1: MCS field is increased to 5 bits to indicate modulation and TBS, and repetition field is reduced to 3 bits to indicate the repetition number;
• Option 2: MCS field is 4 bits to indicate TBS, and repetition field is reduced to 3 bits to indicate the repetition number;
• 1 bit is used to indicate legacy QPSK or 16QAM
• Option 3: MCS field is 4 bits to indicate modulation and TBS
• A reserved state of MCS field indicates use of 16QAM,
• Repetition field indicates 16QAM MCS if 16QAM is indicated to be used.
• Option 4: MCS is 4 bits,
• If repetition is indicated as one, 16QAM and QPSK can be indicated by MCS field;
• If repetition is indicated larger than one, the legacy QPSK MCS can be indicated by MCS field.
• Option 5: {repetition, MCS} are indicated by 8 bits (a combination of the MCS field and repetition field)
• Note: other options are not precluded.

Agreement

For downlink power allocation to support 16QAM:

• For standalone and guard-band deployments:

o   Option 1: Two power ratios are signaled

§  NPDSCH EPRE to NRS EPRE in symbols with NRS

§  NPDSCH EPRE to NRS EPRE in symbols without NRS

o   Option 2: the power ratio of NPDSCH EPRE to NRS EPRE in symbols with NRS is signaled, assuming the same transmit power of different symbols.

o   Option 3: the power ratio of NPDSCH EPRE to NRS EPRE in symbols without NRS is signaled, assuming the same transmit power of different symbols.

o   If the signaling(s) is(are) not indicated, the legacy power allocation is used.

§  i.e., the ratio of NPDSCH EPRE to NRS EPRE is 0dB for one NRS antenna port, and -3dB for two NRS antenna ports

• For inband deployments, the power ratio of NRS EPRE to CRS EPRE is signaled in addition to the signaling for standalone and guard-band deployments.

o   FFS to reuse the existing parameter nrs-CRS-PowerOffset.

• FFS: Whether UE specific or cell-specific or carrier-specific signaling is used

Agreement

If 16-QAM is configured for NPDSCH, the channel quality report for 16-QAM is based on NPDSCH transport block that achieves an error probability not exceeding 10% BLER.

For future meeting:

• Additional power control parameter for 16-QAM (e.g. similar to Δ_TF)
• Applicability of 16QAM for PUR and multi-TB scheduling

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2102358         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2102653         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

R1-2102858         Remaining issues on 14-HARQ processes in DL for eMTC      ZTE

R1-2103068         Support of 14 HARQ processes and scheduling delay Qualcomm Incorporated

R1-2103464         Design considerations to support 14-HARQ Feature for LTE-M             Sierra Wireless, S.A.

R1-2103724         Support of 14 HARQ processes in DL in LTE-MTC   Ericsson

[104b-e-LTE-Rel17_NB_IoT_eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

-        1^st check point: April 15

-        2^nd check point: April 20

R1-2103859        Feature Lead Summary [104b-e-LTE-Rel17_NB_IoT_eMTC-02] 1st check point               Moderator (Ericsson)

Agreement

In Rel-17, for the 14 HARQ processes feature, PUCCH repetition is not supported with HARQ-ACK bundling.

Conclusion

In Rel-17, the 14 HARQ processes feature is not supported when the multi-TB grant feature is enabled.

R1-2103860        Feature Lead Summary [104b-e-LTE-Rel17_NB_IoT_eMTC-02]: 2nd check point      Moderator (Ericsson)

Agreement

In Rel-17, for the 14 HARQ process feature the HARQ-ACK delay solution will be down-selected in RAN1#105-e from:

·        Alt-1: The HARQ-ACK delay is determined through an expression consisting of different subframe types (Using a similar principle as the PDSCH scheduling delay).

o   FFS: The expression consisting of different subframe types.

o   FFS: Signaling Details.

·        Alt-2: The HARQ-ACK delay is determined following the legacy approach. That is, the “HARQ-ACK delay” is kept expressed in terms of “absolute subframes”.

o   FFS: The percentage of presence of non-BL/CE DL subframes and non-BL/CE UL subframes to be handled.

o   FFS: HARQ-ACK delay values and length of the HARQ-ACK delay set.

o   FFS: Signaling Details.

The following aspects will be considered towards the down-selection of one of the two alternatives (i.e., Alt-1 or Alt-2) for the HARQ-ACK delay solution:

·        Total number of bits required in DCI

·        Scenarios that can be handled, including:

o   different numbers of scheduled HARQ processes per burst (including dynamically switching between more than 10 HARQ processes and 10 or less HARQ processes)

o   different % of invalid subframes for both 10 and 40 SF long bitmaps

·        Robustness against loss of DCIs

·        Flexibility

·        RRC signaling overhead

8.9.3        Support a maximum DL TBS of 1736 bits as a Rel-17 optional UE capability

For HD-FDD Cat. M1 UEs in CE mode A only

R1-2102359         Support of a max DL TBS of 1736 bits in LTE-MTC Huawei, HiSilicon

R1-2102654         Support of a maximum DL TBS of 1736 bits for eMTC            Nokia, Nokia Shanghai Bell

R1-2102859         Remaining issues on DL TBS increase for eMTC       ZTE

R1-2103069         Support of larger TBS for eMTC     Qualcomm Incorporated

R1-2103313         Remaining issues for support of DL TBS of 1736 bits for eMTC            Sony

R1-2103462         Design considerations to support DL TBS of 1736 bits for LTE-M         Sierra Wireless, S.A.

R1-2103725         Support of a maximum DL TBS of 1736 bits in LTE-MTC      Ericsson

R1-2104086        Feature Lead Summary [104b-e-LTE-Rel17_NB_IoT_eMTC-03]    Moderator (Sony)

//Handled under NWM – See RAN1-104b-e-NWM-LTE-Rel17_NB_IoT_eMTC-03 as the document name

[104b-e-LTE-Rel17_NB_IoT_eMTC-03] – Martin (Sony)

Email discussion on support of a max TBS of 1736 bits

-        1^st check point: April 15

-        2^nd check point: April 20

R1-2104087        Summary of NWM discussion for [104b-e-LTE-Rel17_NB_IoT_eMTC-03]               Moderator (Sony)

Agreement

The working assumption on the value of N is confirmed for the calculation of the number of soft channel bits based on the equation:

where N=8.

Agreement

The soft channel bits for UEs supporting maximum DL TBS of 1736 bits is 43008 bits.

Agreement

Send an LS to RAN2 informing them of RAN1’s decisions on the following:

• The soft channel bits for UEs supporting maximum DL TBS of 1736 bits is 43008 bits.
• The 1736 bits DL TBS feature is enabled by unicast RRC configuration.

R1-2103942        LS on Agreements Related to Support of a maximum DL TBS of 1736 bits as a Rel-17 optional UE capability       RAN1, Sony

Decision: As per decision posted on April 16^th, the LS is approved.

8.9.44        Other

Void (not be handled during this e-meeting). No contributions please.

 RAN1#105-e

8.9       Rel-17 enhancements for NB-IoT and LTE-MTC

Please refer to RP-201306 for detailed scope of the WI

R1-2106233        Session notes for 8.9 (Rel-17 enhancements for NB-IoT and LTE-MTC)        Ad-hoc Chair (Samsung)

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2104288         Support of 16QAM for unicast in UL and DL in NB-IoT           Huawei, HiSilicon

R1-2104548         Support of 16-QAM for NB-IoT     Nokia, Nokia Shanghai Bell

R1-2104716         Discussion on UL and DL 16QAM for NB-IoT           ZTE

R1-2104819         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

R1-2105374         Support 16QAM in NB-IOT Release 17        MediaTek Inc.

R1-2105622         Support 16QAM for NBIoT             Lenovo, Motorola Mobility

R1-2105889         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

[105-e-LTE-Rel17_NB_IoT_eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT

·        1^st check point: May 24

·        2^nd check point: May 27

R1-2106042        Feature lead summary #1 on 105-e-LTE-Rel17_NB_IoT_eMTC-01 Moderator (Huawei)

From GTW sessions:

Agreement

·        Support 16-QAM for multi-TB scheduling.

Working Assumption

Support 16-QAM for NPUSCH in PUR procedure.

·        FFS on support of 16-QAM for NPDSCH in PUR procedure.

Agreement

Confirm the working assumption.

·        The DCI size is not increased to support 16-QAM in uplink and downlink.

Agreement

For the indication of 16-QAM in downlink:

·        The “Modulation and coding scheme” field in DCI Format N1 is utilized as in legacy for scheduling QPSK.

·        One reserved state in the “Modulation and coding scheme” field in DCI Format N1 is utilized to indicate the use of 16QAM.

·        The “Repetition number” field in DCI Format N1 is utilized to indicate the TBS indices for 16-QAM in DL when the reserved state in MCS field is indicated.

·        FFS: The manner of distinguishing the different ranges of TBS indices for “Stand-alone/Guard-band” (i.e., I_TBS indices from 14 to 21) and “In-band” (i.e., I_TBS indices from 11 to 17) deployments.

Working Assumption

For downlink power allocation to support 16QAM:

·        For standalone and guard-band deployments:

o   One power ratio is signaled optionally

§  NPDSCH EPRE to NRS EPRE in symbols without NRS

o   The same transmit power is assumed across different symbols.

o   If the signalling is not indicated, the legacy power allocation is used.

§  i.e., the ratio of NPDSCH EPRE to NRS EPRE is 0dB for one NRS antenna port, and -3dB for two NRS antenna ports

·        UE specific signalling is used

Agreement

·        Introduce a new term in uplink power control of NPUSCH using 16-QAM. FFS on the details.

Agreement

·        When configured with downlink 16-QAM, the channel quality can be reported in MAC CE.

o   FFS on support in Msg3 in connected mode

R1-2106104        Feature lead summary #2 on 105-e-LTE-Rel17_NB_IoT_eMTC-01 Moderator (Huawei)

Agreement

On the indication of downlink 16-QAM, when the reserved state in MCS field is indicated, the “Repetition number” field in DCI Format N1 is utilized to indicate the TBS indices

·        From 14 to 21 for standalone/guardband deployments,

·        From 11 to 17 for inband deployment.

·        FFS: How UE distinguishes the deployment

R1-2106219        Feature lead summary #3 on 105-e-LTE-Rel17_NB_IoT_eMTC-01 Moderator (Huawei)

Working Assumption

For the indication of 16-QAM in uplink

·        The “Modulation and coding scheme” field in DCI Format N0 is utilized as in legacy for scheduling QPSK.

·        One reserved state in the “Modulation and coding scheme” field in DCI Format N0 is utilized to indicate the use of 16QAM.

·        The “Repetition number” field in DCI Format N0 is utilized to indicate the TBS indices (i.e., I_TBS indices from 14 to 21) for 16-QAM in UL.

Agreement

For CQI table for downlink 16-QAM, down-select between following options in RAN1#106-e:

·        Option 1: More than three candidate values for 16-QAM are added in the legacy table.

o   FFS: Which of the legacy entries are removed

·        Option 2: Three candidate values for 16-QAM are added in the legacy table.

·        Option 3: A new CQI table is defined for 16-QAM based on the eMTC table (CQI Tables in 36.213) as a starting point

Agreement

For downlink power allocation to support 16QAM:

• For inband deployments, a power ratio is signaled in addition to the signalling for standalone and guard-band deployments which in this case applies to “symbols with NRS” and “symbols without NRS nor CRS”. Down-select from the following options in RAN1#106-e:
• Alt 1:
• The existing parameter nrs-CRS-PowerOffset is reused for same PCI case, and is signaled for different PCI case.
• The same transmit power of different symbols is assumed as to derive from nrs-CRS-PowerOffset the NPDSCH EPRE in symbols with CRS.
• Alt 2:
• the power ratio between NPDSCH EPRE and NRS EPRE in symbols with CRS is signaled
• FFS: NPDSCH EPRE to NRS EPRE in symbols with NRS

FFS: Whether UE specific or cell-specific or carrier-specific signalling is used.

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2104289         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2104549         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

R1-2104717         Remaining issues on 14-HARQ processes in DL for eMTC      ZTE

R1-2104821         Support of 14 HARQ processes and scheduling delay Qualcomm Incorporated

R1-2105890         Support of 14 HARQ processes in DL in LTE-MTC   Ericsson

[105-e-LTE-Rel17_NB_IoT_eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

·        1^st check point: May 24

·        2^nd check point: May 27

R1-2106028        Feature Lead Summary [105-e-LTE-Rel17_NB_IoT_eMTC-02] checkpoint#1               Moderator (Ericsson)

From GTW sessions:

Agreement

In Rel-17, for the 14 HARQ process feature the HARQ-ACK delay solution will be supported with multiple solutions:

Alt-1 for full flexibility and Alt-2e for support of legacy delay

·        Alt-1: The HARQ-ACK delay is determined through an expression consisting of different subframe types (Using a similar principle as the PDSCH scheduling delay).

o   Without using more than 6 bits

o   FFS: How to minimize the overhead by using joint encoding

·        Alt-2e: The HARQ-ACK delay is determined following the legacy approach. That is, the “HARQ-ACK delay” is kept expressed in terms of “absolute subframes”.

o   The HARQ-ACK delay values and the length of the HARQ-ACK delay set will be based on

§  Alt-2e: “3 bits (same as legacy)”

§  FFS: Whether HARQ delay set is to use range1 or range2

·        RRC signaling will be used to configure between Alt-1 and Alt-2e

·        FFS: Signaling details

·        FFS: Joint encoding

R1-2106029        Feature Lead Summary [105-e-LTE-Rel17_NB_IoT_eMTC-02] checkpoint#2               Moderator (Ericsson)

Working Assumption

The PDSCH scheduling delay and HARQ-ACK delay are jointly encoded in a single DCI field:

·        The field uses no more than 7 bits if Alt-1 is configured.

·        The field is 5 bits if Alt-2e is configured.

·        FFS: Details of the joint encoding.

·        FFS: Legacy DCI fields that might be re-purposed for the jointly encoded solution of Alt-1 and Alt-2e respectively.

Note: Alt-1 expresses the HARQ-ACK delay as: (y) BL/CE DL subframe + 1 subframe + (z) BL/CE UL subframes, where y = {0, 1, 2, … 11} and z = {1, 2, 3}.

Conclusion:

In Rel-17, for the 14 HARQ processes feature:

When the HARQ-ACK delay is configured to use Alt-1 “PUCCH using Repetition = 1 is postponed”, whereas when the HARQ-ACK delay is configured to use Alt-2e “PUCCH using Repetition = 1 is not postponed (legacy behavior)”.

Agreement

In Rel-17, the 14 HARQ processes feature is applicable for HD-FDD Cat M1 UEs in CE Mode A only.

For discussion in future meetings:

Whether 14 HARQ processes feature can be enabled for PDSCH repetition case

8.9.33        Other

Including any remaining issues in supporting a maximum DL TBS of 1736 bits as a Rel-17 optional UE capability

R1-2104718         Remaining issues on DL TBS of 1736 bits for CE mode A       ZTE

R1-2105891         On the L2 Buffer Size for NB-IoT and LTE-M UEs    Ericsson

R1-2105939         Discussion on DL PAPR for 16-QAM of NB-IoT       Huawei, HiSilicon

[105-e-LTE-Rel17_NB_IoT_eMTC-03] – Martin (Sony)

Email discussion on support of a max TBS of 1736 bits

-        1^st check point: May 24

-        2^nd check point: May 27

R1-2106256        Feature Lead Summary [105-e-LTE-Rel17_NB_IoT_eMTC-03]       Moderator (Sony)

Decision: As per email decision posted on May 27^th, there is no conclusion made or agreements endorsed.

 RAN1#106-e

8.9       Rel-17 enhancements for NB-IoT and LTE-MTC

Please refer to RP-211340 for detailed scope of the WI

R1-2108609        Session notes for 8.9 (Rel-17 enhancements for NB-IoT and LTE-MTC)        Ad-hoc Chair (CMCC)

R1-2107687         Work plan of Rel-17 enhancements for NB-IoT and LTE-MTC              Huawei, Ericsson

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2106558         Support of 16QAM for unicast in UL and DL in NB-IoT           Huawei, HiSilicon

R1-2106654         Support of 16-QAM for NB-IoT     Nokia, Nokia Shanghai Bell

R1-2106758         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

R1-2106847         Discussion on UL and DL 16QAM for NB-IoT           ZTE, Sanechips

R1-2107508         Support 16QAM in NB-IOT            MediaTek Inc.

R1-2107941         Support 16QAM for NBIoT             Lenovo, Motorola Mobility

R1-2108116         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

[106-e-LTE-Rel17_NB_IoT_eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT

• 1^st check point: 8/19
• 2^nd check point: 8/24
• Final check: 8/27

R1-2108275        Feature lead summary #1 on 106-e-LTE-Rel17_NB_IoT_eMTC-01 Moderator (Huawei)

From GTW session:

Agreement:

Confirm the following working assumption:

·        Working Assumption

o   Support 16-QAM for NPUSCH in PUR procedure.

Confirm the working assumption:

Working Assumption

·        For the indication of 16-QAM in uplink

·        The “Modulation and coding scheme” field in DCI Format N0 is utilized as in legacy for scheduling QPSK.

·        One reserved state in the “Modulation and coding scheme” field in DCI Format N0 is utilized to indicate the use of 16QAM.

·        The “Repetition number” field in DCI Format N0 is utilized to indicate the TBS indices (i.e., I_TBS indices from 14 to 21) for 16-QAM in UL.

Agreement

For the UE configured with 16-QAM for NPDSCH, the deployment of the carrier is signaled by operationModeInfo in MIB or inbandCarrierInfo in SIB.

Confirm working assumption:

Working Assumption

·        For downlink power allocation to support 16QAM:

o   For standalone and guard-band deployments:

§  One power ratio is signalled optionally

·        NPDSCH EPRE to NRS EPRE in symbols without NRS

§  The same transmit power is assumed across different symbols.

§  If the signalling is not indicated, the legacy power allocation is used.

·        i.e., the ratio of NPDSCH EPRE to NRS EPRE is 0dB for one NRS antenna port, and -3dB for two NRS antenna ports

o   UE specific signalling is used

Agreement

Down-select one option from Cat 1 as starting point

·        Cat 1: Option 1, Option 2/Option 4, Option 5

FFS Cat 2: Option 3, for close-loop power control

·      Option 1: Reuse the LTE definition simplified for NB-IoT:  for  and  for , where  is given by higher layer parameter deltaMCS-Enabled, and  where K is the code block size.

·        Option 2:  is given in table based on MCS index if enabled, 0 otherwise.

·        Option 3: A TPC command is introduce to indicate the power offset for NPUSCH with 16-QAM.

·        Option 4:  is configured by high layer parameter.

·        Option 5: Δ_TF =  for K_s = 1.25 or Δ_TF = 0 for K_s = 0, where BPRE =.  is the highest code rate in the TBS/MCS table used for the Modulation Scheme, and  is the number of bits per M-ary symbol of the Modulation Scheme.

R1-2108466        Feature lead summary #2 on 106-e-LTE-Rel17_NB_IoT_eMTC-01 Moderator (Huawei)

From GTW session:

Working Assumption

For downlink power allocation to support 16QAM:

• For inband deployments, a power ratio is signaled in addition to the signalling for standalone and guard-band deployments which in this case applies to “symbols with NRS” and “symbols without NRS nor CRS”.

• the power ratio between NPDSCH EPRE and NRS EPRE in symbols with CRS is signalled
• the signalling is UE specific

Note: “symbols with NRS” and “symbols without NRS nor CRS” have the same power.

Conclusion

The channel quality report is not supported in Msg3 in connected mode in Rel-17.

R1-2108530         Feature lead summary #3 on 106-e-LTE-Rel17_NB_IoT_eMTC-01      Moderator (Huawei)

Final summary in R1-2108642.

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2106559         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2106661         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

R1-2106759         Support of 14 HARQ processes and scheduling delay Qualcomm Incorporated

R1-2106848         Remaining issues on 14-HARQ processes in DL for eMTC      ZTE, Sanechips

R1-2108117         Support of 14 HARQ processes in DL in LTE-MTC   Ericsson

[106-e-LTE-Rel17_NB_IoT_eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

• 1^st check point: 8/19
• 2^nd check point: 8/24
• Final check: 8/27

R1-2108295        Feature Lead Summary [106-e-LTE-Rel17_NB_IoT_eMTC-02] - 1st check point               Moderator (Ericsson)

From GTW session:

Agreement

Confirm the below Working Assumption for Alt-2e with following updates

The PDSCH scheduling delay and HARQ-ACK delay are jointly encoded in a single DCI field:

·        The field is 5 bits if Alt-2e is configured.

·        FFS: Details of the joint encoding.

·        FFS: Legacy DCI fields that might be set to zero bits in length for the jointly encoded solution Alt-2e.

For Alt-1, it will be separate discussion based existing working assumption

Agreement

Confirm the below Working Assumption for Alt-1 with following updates

The PDSCH scheduling delay and HARQ-ACK delay are jointly encoded in a single DCI field:

·        The field is no more than 7 bits if Alt-1 is configured.

·        FFS: Details of the joint encoding.

·        FFS: Legacy DCI fields that might be set to zero bits in length for the jointly encoded solution Alt-1.

Note: Alt-1 expresses the HARQ-ACK delay as: (y) BL/CE DL subframe + 1 subframe + (z) BL/CE UL subframes, where y = {0, 1, 2, … 11} and z = {1, 2, 3}.

R1-2108296        Feature Lead Summary [106-e-LTE-Rel17_NB_IoT_eMTC-02] - 2st check point               Moderator (Ericsson)

From GTW session:

Agreement

For the PDSCH scheduling delay and HARQ-ACK delay jointly encoded in a single DCI field:

·        The DCI field uses 7 bits if Alt-1 is configured.

Conclusion

How to implement/describe the states, e.g., table, resulting from the joint encoding solution of Alt-1 is left up to the Editor, based on the agreements for the PDSCH scheduling delay, HARQ-ACK delay and the WA confirmed for Alt-1.

8.9.33        Other

Including any remaining issues in supporting a maximum DL TBS of 1736 bits as a Rel-17 optional UE capability

R1-2107684         Discussion on DL PAPR for 16-QAM of NB-IoT       Huawei, HiSilicon

R1-2108118         On Rel-17 RRC parameters and specification impacts for LTE-M and NB-IoT               Ericsson

 RAN1#106-bis-e

8.9       Rel-17 enhancements for NB-IoT and LTE-MTC

Please refer to RP-201306 for detailed scope of the WI

R1-2110618        Session notes for 8.9 (Rel-17 enhancements for NB-IoT and LTE-MTC)        Ad-hoc Chair (CMCC)

[106bis-e-R17-RRC-NB-IoT-eMTC] – Yubo (Huawei)

Email discussion on Rel-17 RRC parameters for Rel-17 NB-IoT and eMTC

-        1^st check point: October 14

-        Final check point: October 19

R1-2110650        Feature lead summary on 106bis-e-R17-RRC-NB-IoT-eMTC           Moderator (Huawei)

Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].

R1-2110691         RAN1 agreements of Additional enhancements for NB-IoT and LTE-MTC         WI rapporteur (Huawei)

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2108777         Support of 16QAM for unicast in UL and DL in NB-IoT           Huawei, HiSilicon

R1-2109174         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

R1-2109314         Support of 16-QAM for NB-IoT     Nokia, Nokia Shanghai Bell

R1-2109320         Support 16QAM for NBIoT             Lenovo, Motorola Mobility

R1-2109337         Discussion on UL and DL 16QAM for NB-IoT           ZTE, Sanechips

R1-2109559         Remaining Issues on supporting 16QAM in NB-IOT R17         MediaTek Inc.

R1-2110316         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

[106bis-e-LTE-Rel17-NB-IoT-eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT

-        1^st check point: October 14

-        Final check point: October 19

R1-2110459        Feature lead summary #1 on 106bis-e-LTE-Rel17-NB-IoT-eMTC-01               Moderator (Huawei)

From Oct 11^th GTW session

Working Assumption

For the new term  introduced for power control of NPUSCH,

·      Reuse the LTE definition simplified for NB-IoT:  for  and  for , where  is given by higher layer parameter deltaMCS-Enabled, and  where K is the code block size.

·        FFS: whether the new term applies to QPSK when configured with 16QAM, if it does not, whether an additional term is introduced to avoid jump between QPSK and 16QAM

Decision: As per email decision posted on Oct 15^th,

Agreement

Support 16-QAM for NPDSCH in PUR procedure

·        CSI report is not supported/expected during PUR procedure.

Agreement

Support 16-QAM for NPDSCH and NPUSCH in PUR procedure,

·        16-QAM can be enabled/disabled by UE specific RRC signaling for NPDSCH and NPUSCH separately

o   The corresponding configurations and signaling details are up to RAN2

Agreement

The reserved state to indicate the use of 16QAM in DCI format N0 and DCI format N1 should be “1111”.

Agreement

Confirm the following working assumption:

Working Assumption

For downlink power allocation to support 16QAM:

·        For inband deployments, a power ratio is signaled in addition to the signaling for standalone and guard-band deployments which in this case applies to “symbols with NRS” and “symbols without NRS nor CRS”.

o   the power ratio between NPDSCH EPRE and NRS EPRE in symbols with CRS is signaled

o   the signaling is UE specific

Note: “symbols with NRS” and “symbols without NRS nor CRS” have the same power.

Agreement

For the UE configured with 16-QAM for NPDSCH, the deployment of the carrier is signaled by operationModeInfo in MIB or inbandCarrierInfo in SIB/UE specific signaling.

Note: Existing agreement from RAN1#106e is "For the UE configured with 16-QAM for NPDSCH, the deployment of the carrier is signaled by operationModeInfo in MIB or inbandCarrierInfo in SIB", which is replaced by the updated agreement above from RAN1#106bis-e.

Final summary in R1-2110555.

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2108778         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2109175         Support of 14 HARQ processes and scheduling delay Qualcomm Incorporated

R1-2109315         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

R1-2109338         Remaining issues on 14-HARQ processes in DL for eMTC      ZTE, Sanechips

R1-2110317         Support of 14 HARQ processes in DL in LTE-MTC   Ericsson

[106bis-e-LTE-Rel17-NB-IoT-eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

-        1^st check point: October 14

-        Final check point: October 19

R1-2110413        Feature Lead Summary [106bis-e-LTE-Rel17-NB-IoT-eMTC-02] - first checkpoint          Moderator (Ericsson)

From Oct 13^th GTW session

Working Assumption

For the joint encoding of “PDSCH Scheduling delay” and “HARQ-ACK delay” when Alt-2e is configured, the HARQ-ACK delay set has a size of:

·        Alt-C:

o   12 elements: HARQ-ACK delay set = {a, b, c, d, e, f, g, h, i, j, k, l} for the PDSCH Scheduling delay expression associated to the delay of 2.

o   10 elements: HARQ-ACK delay set = {o, p, q, r, s, t, u, v, x, w} for the two PDSCH Scheduling delay expressions associated to the delay of 7.

o   FFS: The values of {a, b, c, d, e, f, g, h, i, j, k, l}, {o, p, q, r, s, t, u, v, x, w} where some of these elements may share the same value.

R1-2110414        Feature Lead Summary [106bis-e-LTE-Rel17-NB-IoT-eMTC-02] - final checkpoint          Moderator (Ericsson)

From Oct 18^th GTW session

Conclusion:

How to implement/describe the states, e.g., table, resulting from the joint encoding solution of Alt-2e is left up to the Editor, based on the agreements for the PDSCH scheduling delay, HARQ-ACK delay and the WA confirmed for Alt-2e.

Agreement

The Rel-17 14 HARQ processes feature only applies to User Specific Search Space (USS).

Agreement (completed and confirmed on Oct 22^nd)

In Rel-17, for the 14 HARQ processes feature the “HARQ-ACK process number” field uses 4-bits.

·        The mapping associated to the 4-bits of this field is updated to include the newly added HARQ processes (i.e., 11^th, 12^th, 13^th, and 14^th HARQ processes).

Agreement

In Rel-17, for the 14 HARQ processes feature the following updates on the technical specification are to be performed.

·        The maximum number of received PDSCH receptions pending HARQ-ACK is set to W = 12 (in Sect. 7.3.1 of TS 36.213) when the UE is configured with 14 HARQ processes.

Agreement

In Rel-17, one option will be down selected from Opt-2 and Opt-3 for the 14 HARQ processes feature the “Repetition number” field in RAN1#107e:

·        Opt-2: 0-bits when the 14 HARQ processes feature is configured (i.e., 2-bits from this field become available for jointly-encoding purposes).

·        Opt-3: 2-bits as in legacy.

8.9.33        Other

Including any remaining issues in supporting a maximum DL TBS of 1736 bits as a Rel-17 optional UE capability.

R1-2110318         On the support of 16-QAM for unicast in UL and DL for TDD NB-IoT Ericsson

R1-2110372         Discussion on RRC parameters for max DL TBS of 1736 bits  Huawei, HiSilicon

 RAN1#107-e

8.9       Rel-17 enhancements for NB-IoT and LTE-MTC

Please refer to RP-211340 for detailed scope of the WI

R1-2112796        Session notes for 8.9 (Rel-17 enhancements for NB-IoT and LTE-MTC)        Ad-hoc Chair (CMCC)

Rel-17 CRs related to enhancements for NB-IoT and LTE-MTC

R1-2112417        Introduction of Additional Enhancements for NB-IoT and LTE-MTC in 36.213 s06-07   Motorola Mobility

R1-2112418        Introduction of Additional Enhancements for NB-IoT and LTE-MTC in 36.213 s10-s13 Motorola Mobility

R1-2112419        Introduction of Additional Enhancements for NB-IoT and LTE-MTC in 36.213 s14-xx   Motorola Mobility

Decision: Draft CRs to 36.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CRs for RAN submission after RAN1#107-e.

R1-2112434        Introduction of additional enhancements for NB-IoT and LTE-MTC               Ericsson

Decision: Draft CR to 36.211 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.

R1-2112496        Introduction of Rel-17 NB-IoT and eMTC features              FUTUREWEI

Decision: Draft CR to 36.212 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.

[107-e-R17-RRC-NB-IoT-eMTC] – Yubo (Huawei)

Email discussion on Rel-17 RRC parameters for Rel-17 NB-IoT and eMTC

-        Email discussion to start on November 15

R1-2112877        Feature lead summary on 107-e-R17-RRC-NB-IoT-eMTC Moderator (Huawei)

Decision: As per email decision posted on Nov 20^th,

Agreement

• The value range for the following RRC parameters is {-6, -4.77, -3, -1.77, 0, 1, 2, 3} dB
• Power ratio of NPDSCH EPRE to NRS EPRE in symbols without NRS for standalone and guard-band deployments, or in symbols without NRS nor CRS for in-band deployments.
• Power ratio of NPDSCH EPRE to NRS EPRE in symbols with CRS for in-band deployments.

Document is noted. For consolidation under 8 in [107-e-R17-RRC].

R1-2112897         RAN1 agreements of Additional enhancements for NB-IoT and LTE-MTC         WI rapporteur (Huawei)

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2110857         Support of 16QAM for unicast in UL and DL in NB-IoT           Huawei, HiSilicon

R1-2111070         Discussion on 16QAM for NB-IoT ZTE, Sanechips

R1-2111133         Support of 16-QAM for NB-IoT     Nokia, Nokia Shanghai Bell

R1-2111449         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

R1-2112001         Support 16QAM for NBIoT             Lenovo, Motorola Mobility

R1-2112300         Discussion on CQI table and NPUSCH power control parameter for 16QAM               MediaTek Inc.

R1-2112361         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

[107-e-LTE-Rel17-NB-IoT-eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT

-        1^st check point: November 15

-        Final check point: November 19

R1-2112576        Feature lead summary #1 on 107-e-LTE-Rel17-NB-IoT-eMTC-01   Moderator (Huawei)

From Nov 11^th GTW session

Agreement

·        Variant of option 1 is agreed in principle, detailed content in following table will be revisited.

o   A new table is defined for the combination of NPDCCH repetitions and NPDSCH MCS

·        FFS: larger number NPDCCH repetition level

Note: The (TBS index X) and SNR are just for information, based on standalone deployment. They will be removed once it’s agreed.

R1-2112651        Feature lead summary #2 on 107-e-LTE-Rel17-NB-IoT-eMTC-01   Moderator (Huawei)

From Nov 16^th GTW session

Agreement

·        The table is taken as working assumption.

Note: The (TBS index X) and SNR are just for information, based on standalone deployment. They will be removed once it’s agreed.

Decision: As per email decision posted on Nov 18^th,

Agreement

The following working assumption is confirmed.

For the new term  introduced for power control of NPUSCH,

·        Reuse the LTE definition simplified for NB-IoT:  for  and  for ,

where  is given by higher layer parameter deltaMCS-Enabled, and  where K is the code block size.

·        FFS: whether the new term applies to QPSK when configured with 16QAM, if it does not, whether an additional term is introduced to avoid jump between QPSK and 16QAM

R1-2112747        Feature lead summary #3 on 107-e-LTE-Rel17-NB-IoT-eMTC-01   Moderator (Huawei)

From Nov 18^th GTW session

Agreement:

The following working assumption is confirmed with following modification

·        The table is endorsed.

Conclusion

There’s no consensus on the introduction of CSI reference resource in NB-IoT in Rel-17, whether/how to introduce CSI reference resource is up to RAN4.

Agreement: The new CQI table is captured in TS 36.133, send LS to RAN2/RAN4 of the agreements on channel quality reporting.

R1-2112970        Draft LS on channel quality reporting for NB-IoT Moderator (Huawei)

Decision: As per email decision posted on Dec 1^st, the draft LS is endorsed. Final version is approved in R1-2112971.

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2110858         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2111071         Remaining issues on 14-HARQ processes in DL for eMTC      ZTE, Sanechips

R1-2111134         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

R1-2111450         Support of 14 HARQ processes and scheduling delay Qualcomm Incorporated

R1-2112362         Support of 14 HARQ processes in DL in LTE-MTC   Ericsson

[107-e-LTE-Rel17-NB-IoT-eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

-        1^st check point: November 15

-        Final check point: November 19

R1-2112517        Summary#1st check point [107-e-LTE-Rel17-NB-IoT-eMTC-02] on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC               Moderator (Ericsson)

From Nov 16^th GTW session

Agreement

Confirm the following Working Assumption:

For the joint encoding of “PDSCH Scheduling delay” and “HARQ-ACK delay” when Alt-2e is configured, the HARQ-ACK delay set has a size of:

·        Alt-C:

o   12 elements: HARQ-ACK delay set = {a, b, c, d, e, f, g, h, i, j, k, l} for the PDSCH Scheduling delay expression associated to the delay of 2.

o   elements: HARQ-ACK delay set = {o, p, q, r, s, t, u, v, x, w} for the two PDSCH Scheduling delay expressions associated to the delay of 7.

FFS: The values of {a, b, c, d, e, f, g, h, i, j, k, l}, {o, p, q, r, s, t, u, v, x, w} where some of these elements may share the same value.

Agreement

For the joint encoding of “PDSCH Scheduling delay” and “HARQ-ACK delay” when Alt-2e is configured, the HARQ-ACK delay sets consist of the following elements:

·        Alt-C2:

o   12 elements: HARQ-ACK delay set = {4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 17} for the PDSCH Scheduling delay expression associated to the delay of 2.

o   elements: HARQ-ACK delay set = {4, 5, 10, 12, 13, 14, 15, 16, 17, 18} for the two PDSCH Scheduling delay expressions associated to the delay of 7.

Agreement

In Rel-17, for the 14 HARQ processes feature the “Repetition number” field is:

·        Opt-3: 2-bits as in legacy

Note: Further optimization for using Repetition number” field is not pursued

Agreement

In Rel-17, for the 14 HARQ processes feature the “HARQ-ACK delay” field is:

·        0-bits when the 14 HARQ processes feature is configured (i.e., 3-bits from this field become available for jointly-encoding purposes).

R1-2112518        Final summary [107-e-LTE-Rel17-NB-IoT-eMTC-02] on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC    Moderator (Ericsson)

8.9.33        Other

Including any remaining issues in supporting a maximum DL TBS of 1736 bits as a Rel-17 optional UE capability.

R1-2111939         Further considerations on Rel-17 NB-IoT and eMTC enhancements      Huawei, HiSilicon

R1-2112363         On the support of 16-QAM for unicast in UL and DL in TDD NB-IoT   Ericsson

 RAN1#107-bis-e

8.99       Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC

Void (not be handled during this e-meeting).

 RAN1#108-e

8.9       Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC

R1-2202789        Session notes for 8.9 (Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC)         Ad-hoc Chair (CMCC)

[108-e-R17-RRC-NB-IoT-eMTC] – Yubo (Huawei)

Email discussion on Rel-17 RRC parameters for Rel-17 NB-IoT and eMTC

-        1^st check point for first LS in [108-e-R17-RRC]: February 24

-        Final check point for second LS in [108-e-R17-RRC] if necessary: March 3

Note: The RRC parameters list for NB-IoT/eMTC in R1-2112975 have been stable and no FFS/TBD left. Therefore, no proposal or issue is proposed in this email thread.

R1-2202939         RAN1 agreements of Additional enhancements for NB-IoT and LTE-MTC         WI rapporteur (Huawei)

8.9.1        Support of 16-QAM for unicast in UL and DL for NB-IoT

R1-2200976         Support of 16QAM for unicast in UL and DL in NB-IoT           Huawei, HiSilicon

R1-2201135         Discussion on remaining issues for NB-IoT 16QAM  ZTE, Sanechips

R1-2201407         Support of 16-QAM for unicast in UL and DL for NB-IoT       Nokia, Nokia Shanghai Bell

R1-2201650         Support of 16-QAM for NB-IoT     Qualcomm Incorporated

R1-2201968         Support 16QAM for NBIoT             Lenovo, Motorola Mobility

R1-2202076         Remaining issue for support 16QAM in NB-IOT R17 MediaTek Inc.

R1-2202277         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

[108-e-R17-NB-IoT-eMTC-01] – Yubo (Huawei)

Email discussion on support of 16-QAM for unicast in UL and DL for NB-IoT

-         1st check point: February 25

-         Final check point: March 3

R1-2202878        Feature lead summary on 108-e-LTE-Rel17-NB-IoT-eMTC-01        Moderator (Huawei)

Decision: As per email decision posted on Mar 2^nd,

Agreement

·        When 16QAM is configured, the new CQI table is used.

Note: There’s no consensus in RAN1 on the use of legacy CQI table when 16-QAM is configured

·        Send LS to RAN2 with this agreement

Note: In the table for channel quality reporting for 16-QAM in DL, the “Code rate x 1024” entry for “candidateRep-B” has been updated from “280” to “140”.

R1-2202879        Draft LS on use of CQI table for NB-IoT DL 16QAM          Moderator (Huawei)

Decision: As per email decision posted on Mar 3^rd, the draft LS is endorsed in principle. Final LS on use of CQI table for NB-IoT DL 16QAM is approved in R1-2202880.

Decision: As per email decision posted on Mar 3^rd,

Agreement

The term ∆TF,ci can also be applied to NPUSCH with QPSK, when 16-QAM is configured.

R1-2202881        Text proposals for NB-IoT 16QAM            Moderator (Huawei)

Agreement

The following TPs captured in R1-2202881 are endorsed.

·        TP for Section 6.3.2, TS36.212

·        TP for Section 16.2.2, TS36.213

·        TP for Section 16.4.1.5, TS36.213

·        TP for Section 16.5.1.2, TS36.213

·        TP for Section 16.2.1.1.1, TS36.213

8.9.2        Support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

R1-2200977         Support of 14-HARQ processes in DL for HD-FDD MTC UEs Huawei, HiSilicon

R1-2201894         Remaining issues for introduction of 14-HARQ processes in DL for eMTC               ZTE, Sanechips

R1-2202278         Support of 14 HARQ processes in DL in LTE-MTC   Ericsson

R1-2202369         Support of 14-HARQ processes in DL for eMTC        Nokia, Nokia Shanghai Bell

[108-e-R17-NB-IoT-eMTC-02] – Gerardo (Ericsson)

Email discussion on support additional PDSCH scheduling delay for introduction of 14-HARQ processes in DL for eMTC

-         1st check point: February 25

-         Final check point: March 3

R1-2202635        Feature Lead Summary [108-e-R17-NB-IoT-eMTC-02]: Final checkpoint               Moderator (Ericsson)

Decision: As per email decision posted on Feb 26^th,

Agreement

The TP to section 5.4.3 of TS36.211 is endorsed.

Agreement

The TP to section 7.1.11 of TS36.213 is endorsed.

Decision: As per email decision posted on Mar 3^rd,

Conclusion

In Rel-17 for the 14 HARQ process feature, the use of the “Repetition Number” field was intended to address adverse radio condition where at most 1 HARQ process along with PDSCH repetitions are suitable to be used.

·        Other scenarios making use of PDSCH repetitions (e.g., combining the use of repetitions/no-repetitions) are not precluded subject to be compliant to the “PDSCH scheduling delays” and “HARQ-ACK delays” introduced in Rel-17.

R1-2202888         Clarification on PDSCH scheduling delay for 14-HARQ processes        Moderator (ZTE), Sanechips, Ericsson, Lenovo

R1-2202889         Correction of parameter name for 14-HARQ processes             Moderator (ZTE), Sanechips, Ericsson, Lenovo

Above two (companies) CRs are not pursued; TPs will be included as part of the relevant editor's CRs.

8.9.33        Other

Including any maintenance issues in supporting a maximum DL TBS of 1736 bits as a Rel-17 optional UE capability.

R1-2202280         Clarification on the support of 16-QAM for NB-IoT in TS 36.212          Ericsson

R1-2202281         Clarification on the support of 16-QAM for NB-IoT in TS 36.213          Ericsson

R1-2202477         Further considerations on Rel-17 NB-IoT and eMTC enhancements      Huawei, HiSilicon

 RAN1#109-e

8.99       Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC

R1-2205567        Session notes for 8.9 (Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC)         Ad-hoc Chair (CMCC)

R1-2205152        Preparation phase discussion on 109-e-Prep-AI8.9 NB-IoT-eMTC   Moderator (Huawei)

R1-2203223         On use of DwPTS for 16QAM NPDSCH in NB-IoT   Huawei, HiSilicon

R1-2203631         Clarifications for DL power allocation for 16-QAM   ZTE, Sanechips

R1-2204082         Support of 16-QAM for unicast in UL and DL in NB-IoT         Ericsson

R1-2204878         Support of 16-QAM in NB-IoT TDD             Nokia, Nokia Shanghai Bell

[109-e-LTE-Rel17-NB-IoT-eMTC-01] – Yubo (Huawei)

Email discussion for Maintenance on support of 16-QAM, including Issue 1 and Issue 2 in R1-2205152

-        Discussion and decision by 5/14

R1-2205153        Feature lead summary on 109-e-LTE-Rel17-NB-IoT-eMTC-01        Moderator (Huawei)

R1-2205375        Text proposals on NB-IoT 16QAM             Moderator (Huawei)

Decision: As per email decision posted on May 13^th,

Agreement

·        Adopt the text proposal in R1-2205375 to TS 36.213, clause 16.2.2.

Decision: As per email decision posted on May 14^th,

Agreement

·        Adopt the text proposal in R1-2205375 to TS 36.211, clause 10.0.1.2.

 RAN1#110

8.99       Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC

R1-2208140        Session notes for 8.9 (Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC)         Ad-hoc Chair (CMCC)

[110-R17-NB_IoT_MTC] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Yubo (Huawei)

R1-2207957        Feature lead summary on 110-R17-NB_IoT_MTC Moderator (Huawei)

R1-2207056         Clarification on TBS range of QPSK for NUPSCH     ZTE, Sanechips

R1-2207958        Clarification on TBS range of QPSK for NUPSCH                Moderator (Huawei)

Agreement

·        Draft CR R1-2207958 is endorsed in principle.

Final CR (36.213, Rel-17, CR#1427, Cat F) is agreed in:

R1-2208251        Clarification on TBS range of QPSK for NUPSCH Moderator (Huawei), HiSilicon, ZTE, Ericsson

R1-2207572        Clarification on the mapping to physical resources for 16-QAM in NB-IoT               Ericsson

Note: RAN1 understands that the proposed change in R1-2207572 for parameter alignment is correct.

R1-2207573         DRAFT CR Clarification on the mapping to physical resources for 16-QAM in NB-IoT         Ericsson

 RAN1#110-bis-e

8.99       Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC

R1-2210685        Session notes for 8.9 (Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC)         Ad-hoc Chair (CMCC)

R1-2210072         DRAFT CR Clarification on the no acquisition of the repetition number via DCI for 16-QAM transmissions in NB-IoT  Ericsson

R1-2210073         On the no repetition number acquisition via DCI for 16-QAM in NB-IoT               Ericsson

[110bis-e-R17-NB-IoT-eMTC-01] – Gerardo (Ericsson)

Email discussion to clarify on the no acquisition of the repetition number via DCI for 16-QAM transmissions in NB-IoT by Oct 14

-        Check on October 12 whether there is consensus for specification change

R1-2210778        Moderator Summary [110bis-e-R17-NB-IoT-eMTC-01]                      Moderator (Ericsson)

To be confirmed in RAN1# 111 if there is consensus to perform a clarification according with the latest update in the Moderator’s summary R1-2210778.

 RAN1#111

8.99       Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC

R1-2212839        Session notes for 8.9 (Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC)         Ad-hoc Chair (CMCC)

Endorsed and contents incorporated below.

[111-R17-NB_IoT_MTC] – Yubo (Huawei)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2211768         DRAFT CR On the no acquisition of the repetition number via DCI for 16-QAM transmissions in NB-IoT   Ericsson

R1-2211769         On the no repetition number acquisition via DCI for 16-QAM in NB-IoT               Ericsson

R1-2212748        Feature lead summary on 111-R17-NB_IoT_MTC Moderator (Huawei)

Agreement

·        The TP to 36.213 from moderator’s final proposal in R1-2212748 is endorsed in principle.

R1-2212976        Correction on repetition number acquisition for NPDSCH and NPUSCH with 16-QAM              Moderator (Huawei)

Decision: The draft CR R1-2212976 is endorsed in principle. Final CR (TS 36.213, Rel-17, CR#1434, Cat F) is agreed in:

R1-2212977        Correction on repetition number acquisition for NPDSCH and NPUSCH with 16-QAM              Moderator (Huawei), Ericsson, Lenovo, Huawei, HiSilicon

 RAN1#112

8.99       Maintenance on Rel-17 enhancements for NB-IoT and LTE-MTC

No contributions submitted to RAN1#112.